Coping With System Integration Challenges in Large Complex Environments

The increasing scope of systems integration poses many challenges for the system integrators. This paper contends that in conventional projects the Systems Integration phase is systematically underestimated. During this phase all unexpected and unforeseen problems surface, where most problems are cross-organizational. When the project size increases with more suppliers, more users, more enterprise processes, and more (intelligent) functionality, then the system integration phase gets tremendously more difficult. In this paper we will bring order to the integration process and discuss an approach and best practices to cope with systems integration in conventional projects. Such level of integration approach is a prerequisite to deal with all added integration complexity in systems with a scope of (intelligent) enterprises. System Integration as part of Systems Engineering Process Introduction System Integration is one of the activities of the Product Creation Process. The Product Creation Process is triggered by a set of product needs and ideas and results in a system that: • fits in customer’s needs and context • can be ordered, manufactured, installed, maintained, serviced, disposed • fits the business needs During Product Creation many activities are performed, such as: feasibility studies, requirements capturing, design, engineering, contracting suppliers, verification, testing, et cetera. A universal organizational instrument is decomposition. Decomposition enables the distribution of work in a concurrent fashion. The complement of decomposition is integration. Every activity that has been decomposed in smaller steps will have to be integrated again to obtain the single desired outcome. System Integration Definitions. System integration constitutes an ongoing flow of activities during the entire systems engineering process. The nature of these ongoing integration activities, however, changes with the changing system maturity and development phase. Early in the project technologies or lower level components are integrated, while at the end of the project the entire system is built from the higher-level subsystems and then verified. As an example of this process, the NASA NPR 7123.1 defines product integration as “The process used to transform the design solution definition into the desired end product of the WBS model through assembly and integration of lower-level validated end products in a form consistent with the product-line life-cycle phase exit criteria and that satisfies the design solution definition requirements.” The 1 NASA NPR 7123.1 – NASA Systems Engineering Processes and Requirements Defense Acquisition Guide (DAG) defines system integration as the “process of incorporating lower level system elements into higher-level system elements in the design solution or the physical architecture”. Challenges with complex system integration. In practice projects hit many problems that are caused by decomposition steps. Whenever an activity is decomposed the decomposed activities run well, however crosscutting functionality and qualities suffer from the decomposition. Lack of ownership, lack of attention, and lack of communication across organizational boundaries are root causes for these problems. The counter measure for these problems is to have continuous attention for the integration. In this paper we will discuss the full integration flow. We will discuss the goal of integration, the relation between integration and testing, what is integration and how to integrate, an approach to integration, scheduling and dealing with disruptive events, roles and responsibilities, configuration management aspects, and typical order of integration problems occurring in real life. Goal of Integration. The goal of integration is to reduce the project risk of being late or the risk of creating an ill performing system. During integration the project team tries to find unforeseen problems as early as possible, in order to solve these problems in time. Integration plays a major role in risk reduction. The word unforeseen indicates the main challenge of integration: How to find problems when you don’t know that they exist at all? Problems can be unforeseen because the knowledge of the creation team is limited. May be nobody on earth did have the knowledge to foresee such a problem, simply because the creation process enters new areas of knowledge. Problems can also be unforeseen due to invalid assumptions. For instance many assumptions are being made early in the design to cope with many uncertainties. The limited intellectual capabilities of us, humans, limit also the degree in which we can oversee all consequences of uncertainties and assumptions we make. A common source of unforeseen problems is interference between functions or components. For example two software functions running on the same processor may perform well individually, but running concurrently may be way too slow, due to cache pollution or memory trashing. System Integration as part of Product Creation Process. The Product Creation Process (PCP) is often prescribed as a sequence of phases with increasing level of realization and decreasing level of risk. This is a useful high-level mental model, however one should realize that most activities have much more overlap in the current dynamic world. The pure waterfall model, where requirements, design, integration and test are sequential phases, is not practical anymore. The problem in today’s complex systems is that the because it relies on a high level of end product knowledge and understanding at the start of the Product Creation Process which is not not yet present, nor practical for most complex projects. Much more practical is an approach with a shifting emphasis as shown in Figure 1. A comparable approach is RUP. Note especially the long ramp-up of the integration, the focus of this paper. The bar at the bottom of this figure shows a typical product creation phasing used in industry. Typical 5 to 8 phases are present, where the naming suggests that integration is an activity nearly at the end. Figure 1 brings the message that system integration actually requires some effort from very early in the project onwards.